home *** CD-ROM | disk | FTP | other *** search
/ The CICA Windows Explosion! / The CICA Windows Explosion! - Disc 2.iso / pdoxwin / pi0994.zip / WINUP9.EXE / DEADLOCK.TXT < prev    next >
Text File  |  1993-12-21  |  18KB  |  460 lines
  1.  
  2.           NOVELL TECHNICAL INFORMATION DOCUMENT
  3.  
  4. TITLE:          Deadlocks with Novell NetWare and Windows
  5. NOVELL PRODUCT and VERSION:     NetWare Client for DOS/Windows
  6.  
  7. ABSTRACT:
  8. These files fix a problem when using Windows or Windows for
  9. WorkGroups on a Novell network.  The symptom is a blank screen 
  10. with a blinking underline curser in the upper-left-hand corner 
  11. of the screen and the workstation hangs.
  12. _________________________________________________________________
  13.  
  14. DISCLAIMER
  15. THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO
  16. NOVELL.  NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS
  17. INFORMATION.  HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS
  18. FOR YOUR INFORMATION ONLY.  NOVELL MAKES NO EXPLICIT OR IMPLIED
  19. CLAIMS TO THE VALIDITY OF THIS INFORMATION.
  20. _________________________________________________________________
  21.  
  22. ADDITIONAL CONFIGURATION
  23.  
  24. Third-Party Product and Version:
  25.  
  26. Windows
  27. Windows for WorkGroups
  28.  
  29.  
  30. SYMPTOM
  31.  
  32. The symptom is a blank screen with a blinking underline curser 
  33. in the upper-left-hand corner of the screen and the workstation 
  34. hangs.  This may happen at any time while in Windows, launching 
  35. a dos box, using a Windows application or exiting Windows.
  36.  
  37. The following is a list of causes/solutions that Novell has 
  38. isolated that can cause/remedy the symptom described above.
  39.  
  40.  
  41. CAUSE
  42.  
  43. IPXODI.COM had a bug in SPX.  During a retry, SPX would jump to
  44. invalid memory causing an invalid opcode exception in v86 mode only
  45. when SPX is being used.  Few applications use SPX.  This usually
  46. manifests itself as a reboot, hung machine, or blank screen with
  47. cursor in upper-left corner.
  48.  
  49. CAUSE
  50.  
  51. LSL.COM had a bug that was GetStackECBPrescanIsPresent destroyed
  52. the return Flag when an ECB was given.  The symptom of this problem
  53. would most likely manifest it self by a workstation hang when using
  54. a protocol stack that expects to get an ECB from the LSL under a
  55. heavy load.
  56.  
  57. CAUSE
  58.  
  59. LSL.COM also had a problem with the "Do Send for Windows" code that
  60. needed a "Start and End Critical Section" call added.
  61.  
  62. CAUSE
  63.  
  64. An incorrect system configuration including memory management.
  65.  
  66. CAUSE
  67.  
  68. Any I/O, memory, or IRQ conflicts may cause this problem.
  69.  
  70. CAUSE
  71.  
  72. Using third-party device drivers or terminate-and-stay-resident
  73. (TSR) programs.
  74.  
  75. CAUSE
  76.  
  77. Lan Card MLID driver's misuse of ECB buffers.
  78.  
  79. CAUSE
  80.  
  81. Third party protocol stacks, such as TCPIP.
  82.  
  83. CAUSE
  84.  
  85. VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COM
  86. driver that was enhanced jointly by Novell and Microsoft.  It
  87. virtualizes requests to the globally loaded IPX driver.  When a
  88. request is made to IPX, VIPX will allocate a request buffer in the
  89. system's global memory, copy the original request to the global
  90. buffer and give the global request to IPX.  When the global request
  91. completes, IPX will call VIPX.  VIPX will then copy any results
  92. back to the original request buffer and call the application that
  93. submitted the request.
  94.  
  95. CAUSE
  96.  
  97. Some Windows applications have been found to create the symptom if when
  98. exiting Windows the application is running in the background in a 
  99. minimized state.  If this occurs, close all applications before
  100. leaving Windows.
  101.  
  102. CAUSE
  103.  
  104. There are occasions when using a Winstart.bat file (which is created
  105. by the user and placed in the Windows directory) may also cause Windows
  106. to hang when exiting Windows.  Avoid a Winstart.bat file if the symptom 
  107. persists.
  108.  
  109.  
  110. CAUSE
  111.  
  112. Microsoft has a patch called VTDA.386 for their Windows 3.1 VTD driver.  
  113. VTDA.386 obtainable from Microsoft.  Their BBS number is 206-936-6735 
  114. and the file to down load is WW0863.EXE.
  115.  
  116.  
  117.  Version Compatibility with Dedicated IPX
  118.  ----------------------------------------
  119. Novell officially ceased maintenance on the dedicated IPX driver
  120. (IPX.OBJ) version 3.10 dated 11-21-91.  The last version of VIPX to
  121. explicitly support that driver is 1.10.  The current version of
  122. VIPX supports IPXODI.COM only.
  123.  
  124.  Packet Size Limitations
  125.  -----------------------
  126. VIPX.386 will only virtualize packets that are 8000 (decimal) bytes
  127. or less.  Any DOS and Windows IPX or SPX applications that use
  128. networks with a physical packet size greater than 8000 bytes may
  129. not work with VIPX.386.  For example, IBM Token Ring can be
  130. configured to run with 16 KB packets.  A request by a DOS or
  131. Windows IPX application to send a 16 KB packet will be truncated to
  132. 8000 bytes.  On the other hand, any 16 KB packet that is received
  133. by the LAN driver will be dropped because VIPX cannot allocate a
  134. packet big enough to handle it.
  135.  
  136.  Memory Manager Limitations
  137.  --------------------------
  138. When a request is passed up from IPX, VIPX will immediately test
  139. the request buffer to see if it is in global memory.  If it is in
  140. global memory, the request will be passed back down to IPX without
  141. any virtualization.  For example, a TSR loaded before Windows is
  142. considered to be in global memory.  If that TSR calls IPX, VIPX
  143. will test the requests and pass them back down to IPX.  This is
  144. done because there is no need to virtualize requests that are
  145. already global.
  146.  
  147. The use of UMA memory complicates the test for global memory. 
  148. There are two basic scenarios.
  149.  
  150. The first scenario is when a TSR has been loaded high before
  151. Windows was loaded.  In this case, IPX requests will come from
  152. global UMA memory.  VIPX will simply pass these requests back down
  153. to IPX.
  154.  
  155. The second scenario is when a TSR is loaded high in a Windows
  156. DOSBOX.  In this case, IPX requests will come from local UMA
  157. memory.  VIPX will virtualize these requests.
  158.  
  159. Some memory managers test for global UMA memory and will work
  160. properly under both scenarios.  However, other memory managers
  161. exist that do not work properly under Windows.  With these drivers,
  162. all local DOSBOX UMAs look as if they are GLOBAL UMAs.
  163.  
  164. In the case of the second scenario when a TSR calls IPX, VIPX will
  165. test the request buffer and think that it is in global UMA memory
  166. when it is really in LOCAL UMA memory.  As a result, VIPX will pass
  167. a local ECB to IPX without virtualization.  The normal result of
  168. this is a hung machine or data corruption.
  169.  
  170.  
  171. SOLUTION
  172.  
  173. Novell strongly recommends that you update your dedicated IPX
  174. driver with IPXODI.COM v2.12, included in DOSUP9 .EXE, when using
  175. versions of VIPX later than 1.10.
  176.  
  177. Because of the problems with LSL.COM, Novell also recommends that
  178. you update your LSL.COM to v2.05.  This version is also available
  179. in DOSUP9 .EXE in the NOVFILES forum of Compuserve.
  180.  
  181. If you are using third-party memory managers and hang, do not load
  182. TSRs using the IPX interface (including IPX itself) high.  Load
  183. then in conventional memory only.
  184.  
  185. Files Needed:     Size     Date      Version  Location
  186.  
  187.     VIPX.386      23855   10-08-93    1.17    WINUP9.EXE
  188.   IPXODI.COM      30247   10-07-93    2.12    DOSUP9 .EXE
  189.      LSL.COM      17805   09-10-93    2.05    DOSUP9 .EXE
  190.  
  191.  
  192. Installation Instructions:
  193.  
  194. 1. Rename or backup the old VIPX.386, IPXODI.COM, and LSL.COM
  195. files.
  196.  
  197. 2. Copy IPXODI.COM and LSL.COM to where the network board's
  198. software is initialized.
  199.  
  200. 3. Copy VIPX.386 to your WINDOWS\SYSTEM directory.
  201.  
  202. 4. Virtualize the network board's IRQ in the [VIPX] section of the
  203. SYSTEM.INI if using IBM LAN SUPPORT.
  204.  
  205. 5. Put TimerCriticalSection=10000 in the [386Enh] section of the
  206. SYSTEM.INI.
  207.  
  208. 6. Download, and implement the VTDA.386 driver from MicroSoft.
  209.  
  210. 7. Reboot the machine and load the ODI drivers.
  211.  
  212. 8. Enter Windows.
  213.  
  214.  
  215. Solution Specifics:
  216.  
  217.  Specialized Configuration Parameters
  218.  ------------------------------------
  219.  
  220. Under most circumstances, VIPX will work fine under the default
  221. configuration.  However, there may be some applications that
  222. require custom configuration of the driver.  This following is a
  223. list of SYSTEM.INI parameters that can be used to configure VIPX:
  224.  
  225. [VIPX]
  226. VipxMappingPages          =[number of 4K pages]  (default = 16)
  227. VipxFailOverSizedPackets  =[ON|OFF|TRUE|FALSE]   (default = OFF)
  228. VirtualizeIrq[0-F]        =[ON|OFF|TRUE|FALSE]   (default = OFF)
  229.  
  230. VIPX Parameters
  231.  
  232.  VipxMappingPages
  233.  ----------------
  234. This is the number of pages that VIPX can use to globalize requests
  235. to the global IPXODI.COM driver.  VIPX is not absolutely guaranteed
  236. to have all of these pages available at any one point, because this
  237. is the requested number of pages for shared global mapping that
  238. VIPX makes to the Windows VMM at initialization time.
  239.  
  240.  VipxFailOverSizedPackets
  241.  ------------------------
  242. This parameter tells VIPX to fail any requests that require more
  243. than the maximum allowed globalization size.  The actual maximum
  244. will vary according to the media the user is using.  The absolute
  245. maximum is 8000 (decimal) bytes.  With media that have smaller
  246. packets than 8000 bytes, the maximum allowed size is the maximum
  247. packet size that can be put onto the media.
  248.  
  249.  VirtualizeIrq[0-F]
  250.  ------------------
  251. VIPX v1.15 or greater avoids a deadlock between the machine and
  252. network board by virtualizing the network board's IRQ.  With ODI
  253. and dedicated IPX (IPX.OBJ) drivers, VIPX will automatically read
  254. the configuration of the network board from the driver and
  255. virtualize the selected IRQs.  However, when using the IBM LAN
  256. Support Program with SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is not
  257. readable from the driver.  The only way to get this information is
  258. to read the network board hardware itself.  The problem with doing
  259. this is that the hardware can be Token Ring, PCN2 or Ethernet. 
  260. VIPX must now be aware of many different hardware configurations. 
  261. Instead of this, VIPX requires the IBM LAN Support user to specify
  262. the network board's IRQ in the [VIPX] section of the SYSTEM.INI. 
  263. IRQs range from 0 to F (hex).  An example is listed below:
  264.  
  265.      [VIPX]
  266.      VirtualizeIrq2=TRUE
  267.      VirtualizeIrq3=TRUE
  268.  
  269. In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPX
  270. can virtualize up to four different LAN IRQs.  The reason for
  271. virtualizing multiple IRQs is to allow other LAN boards and
  272. protocols to be installed on the same PC and prevent them from
  273. deadlocking the machine.  For example, you may have IPX running
  274. through an NE2000 board on IRQ 3 and TCP/IP running through to an
  275. IBM Token-Ring board on IRQ 2.
  276.  
  277.  TimerCriticalSection
  278.  --------------------
  279. As of version 1.15 of VIPX, TimerCriticalSection is required to be
  280. set on.  The recommended setting is as follows:
  281.  
  282.      [386Enh]
  283.      TimerCriticalSection=10000
  284.  
  285. The reason for this parameter is to avoid a deadlock with the LAN
  286. IRQ Virtualization code.  See "VirtualizeIrq[0-F]" section.
  287.  
  288. Changes to LSL.COM v2.05
  289.  
  290. 1. GetStackECBPrescanIsPresent destroyed the return Flag when an
  291. ECB was given.  The symptom of this problem would most likely
  292. manifest it self by a workstation hang when using a protocol stack
  293. that expects to get an ECB from the LSL under a heavy load.
  294.  
  295. 2. Added a line to correct ECBLISTHEAD overwriting of variable
  296. StackECBHoldQHead.
  297.  
  298. Changes to LSL.COM v2.02
  299.  
  300. 1. Commandline Switches:
  301.  
  302. Valid switches:  U, F, ?, H, C=
  303.  
  304. Only the "U, ?, C=" are documented in the help.
  305.  
  306. U    Used to unload LSL.
  307.  
  308. ?    Used for Help.
  309.  
  310. F    Used to force the unload.
  311.  
  312. H    Used as an equivalent to "?" switch, and is used by
  313.      many of Novell's other utilities.
  314.  
  315. C=   Used to change the path or filename of the configuration
  316.      file. The "C=" switch is the only two-letter switch that is
  317.      valid,  Custom Configuration Files.  When using the "C="
  318.      command-line switch, the LSL first tries the
  319.      [path]\filename as given.  If the file is not found, then
  320.      the filename is searched for in the directory where the LSL
  321.      was loaded from; and if it still cannot be found, it looks
  322.      in the current working directory.  If all these efforts
  323.      fail, then the LSL reverts back to looking for a "NET.CFG"
  324.      file in the directory where the LSL was loaded from then in
  325.      the current working directory.  The filename is considered
  326.      valid even if the path was incorrect.  After parsing the
  327.      Configuration file, the  LSL displays the relative path of
  328.      the Configuration file that was parsed.
  329.  
  330. 2. LSL.COM had a number of bugs and one was a bug that caused a
  331. deadlock situation with the LAN adapter.  A Do Send for Windows
  332. needed a Start and End Critical Section call added.  It is now
  333. language enabled.
  334.  
  335. 3. Multiple Prescan Stack Chaining did not pass a packet properly.
  336.  
  337. 4. GetProtocolControlEntry would not return the DefaultProtocol
  338. Control Entry point if it was not the only stack in the
  339. DefaultProtocolChain.
  340.  
  341. 5. Bound checking was added on the MLID Support Functions.
  342.  
  343. 6. Error code not preserved in Deregister Prescan Tx chain.
  344.  
  345. 7. A bug in Memory Calculation when calculating the amount of
  346. memory to reserve when going TSR was fixed.
  347.  
  348. 8. The LSL, while checking for boards and Protocols that were still
  349. registered would unload from memory, leaving the still registered
  350. entities with bad pointers.  The LSL will now remove all the MLIDS,
  351. through the SHUTDOWN command.  The LSL will not unload if a
  352. Protocol stack is still registered with the LSL.
  353.  
  354. 9. On Installation of a LAN driver, the LSL would check the version
  355. of the Configuration Table and delete the board number.  This is
  356. now fixed.
  357.  
  358. 10. On unload of a LAN driver, the driver called
  359. MLIDSUP_DEREGISTER_MLID, which called MLIDSUP_CONTROL_STACK_FILTER.
  360.  
  361. When testing for board numbers that are bound to the MLID, a JNE
  362. was used where a JE was needed.
  363.  
  364. IPXODI.COM
  365.  
  366. Command line Switches:
  367.  
  368. Valid switches: /?, /D, /A, /C=, /U, /F
  369.  
  370. ?    Used for help screen.
  371.  
  372. D    Used for Eliminate Diagnostic Responder; reduces size
  373.      by 3 KB.
  374.  
  375. A    Used for Eliminate Diagnostic Responder and SPX;
  376.      reduces size by 9 KB.
  377.  
  378.      PLEASE NOTE:  Disabling SPX will mean that SPX
  379.      applications (such as RPRINTER, BTRIEVE, RCONSOLE, or
  380.      Netware for SAA STRNRTR) will not be supported on this
  381.      workstation.
  382.  
  383. C=   Used to change the path or filename of the
  384.      configuration file.  "C=" is the only two letter switch
  385.      that is valid.  If the *.CFG file used does not exist a
  386.      message will be displayed that the standard NET.CFG
  387.      file will be used instead.
  388.  
  389. U    Used to unload.
  390.  
  391. F    Used to force the unload.
  392.  
  393.  IPXODI.COM v2.12 Released for NetWare 4.01 Update
  394.  
  395. 1. Fixed SPX problem that was seen using NASI/NACS modem sharing
  396. data.  This problem shows up when using an SPX applications that is
  397. transferring data in full duplex mode (most SPX applications do not
  398. do this).  The code was advancing the session sequence number in
  399. the local session table immediately after sending an SPX data
  400. packet to the other side.  If a data packet came in from the other
  401. side that did not acknowledge Novell's "send," Novell would
  402. generate a system packet back to the other end with the session
  403. sequence number set to the value in the local session table, which
  404. is one higher than what it should be.  Then if Novell's data packet
  405. got dropped, Novell would retransmit it, in which case the other
  406. end would ignore our packet since it session sequence number was
  407. not high enough.  This would result in session failure.
  408.  
  409. 2. Enhanced initialization code to check the board's node ID for
  410. all 0FFs.  If it is then we display an error and fail to load. 
  411. This enhancement was requested by Novell Austin for support of his
  412. serial line ODI drivers which set the node Id to all 0FFs if the
  413. user hasn't made a connection.  A new error message has been
  414. created for this condition, however the code checks to see if the
  415. msg file IPXODI is using has the new error message.  If it does
  416. not, then the error condition is ignored and IPXODI still loads. 
  417. This will allow current/older msg files to be used successfully.
  418.  
  419. 3. A problem in RxHandler was fixed that was introduced in IPXODI
  420. v2.00 where in the case Novell steals a mapping ECB then they have
  421. to have VIPX get a client receive ECB.  Novell was not preserving
  422. register AX, which was supposed to have the destination socket
  423. number.  In this case, VIPX would return that there was not any
  424. receive ECB since it thought the socket was not opened when in
  425. reality it was and it had receives posted.  This bug can cause
  426. back-to-back receive packets to be dropped when the packets are
  427. destined for an IPX application (DOS or Windows) running under
  428. Enhanced mode Windows.
  429.  
  430. 4. Novell fixed IPX diagnostic responder code so it would return a
  431. 0FFFFh in the SPX socket number field of the IPX diagnostic query
  432. reply packet when SPX or diagnostic portion of IPXODI has not be
  433. loaded by the user.  This provides a method for diagnostic
  434. applications to determine if SPX is there or not so they do not
  435. have to attempt a SPX connect request if SPX is not there.
  436.  
  437.  IPXODI.COM 04-23-93 v2.11 Released for NMS and NetWare 4.01 
  438.  Release
  439.  
  440. 1. Implemented fix in SPX.ASM SPXConnectHandler routine where it
  441. was not preserving the session count in CX when comparing the
  442. session addresses.  This problem exists in the dedicated IPX/SPX
  443. module as well.  To see this problem the same source connection ID
  444. would have to be in use by two nodes trying to connect to a
  445. particular node.
  446.  
  447. 2. Novell fixed a bug in SPXMessageHandler routine where it was
  448. setting the a send ECB's ESR to SessionSendCompletedDelayed without
  449. a group "CGroup:" override that caused a bogus offset to be put in
  450. the ESR offset field.  Thus when the active send finished it would
  451. blow up.  This problem exists in the dedicated IPX/SPX module as
  452. well.  This problem showed itself while running the Novell NMS
  453. Windows application for a few hours.
  454.  
  455. 3. IPXODI.COM had a bug in SPX.  During a retry, SPX would jump to
  456. invalid memory causing an invalid opcode exception in v86 mode only
  457. when SPX is being used.  Few applications use SPX.  This usually
  458. manifests itself as a reboot, hung machine, or blank screen with
  459. cursor in upper-left corner.
  460.